home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 786 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.2 KB
  1. Path: chronicle.mti.sgi.com!austern
  2. From: clamage@Eng.Sun.COM (Steve Clamage)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Bit-field specification incomplete?
  5. Date: 19 Mar 1996 12:07:17 PST
  6. Organization: Sun Microsystems Inc.
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4in39p$krf@engnews1.Eng.Sun.COM>
  9. References: <sdouglas-1903961604090001@193.131.176.202>
  10. Reply-To: clamage@Eng.Sun.COM
  11. NNTP-Posting-Host: isolde.mti.sgi.com
  12. X-Original-Date: 19 Mar 1996 19:52:25 GMT
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMU8UIEy4NqrwXLNJAQE8igH/d0UYakGx4tyEh8z6WAgyrC1lF4PJpwOc
  15.     D/UvCYwU976zQ+FXZSlT39dYKxxLWNY/Ay+oj/ILN9utXIQXhqXmYA==
  16.     =vulz
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. In article 1903961604090001@193.131.176.202, sdouglas@armltd.co.uk (scott douglass) writes:
  20. >
  21. >I was surprised to find that section 9.6, Bit-fields, does not prohibit
  22. >'struct T { int i:-1; };' or 'struct T { int i:0; };' which are constraint
  23. >violations in the C standard.
  24.  
  25. That looks to me like an oversight in the draft.
  26.  
  27. >  It also does not explicitly state that the
  28. >member must act as an integer of the specified numbers of bits.
  29.  
  30. I believe that is deliberate. The actual amount of space allocated is
  31. implementation-dependent, as long as it is at least the amount specified.
  32. If you specify a "long" member bitfield of 8 bits, the actual behavior will
  33. be implementation-dependent. If you specify a bitfield wider than the
  34. type, there is no portable way to determine what happens to the extra bits.
  35. Example: Suppose type short is 16 bits, and you write
  36.     short data : 24;
  37. You can expect to store any short value in the bitfield and get that
  38. value back when you read the bitfield. Anything beyond that, including
  39. what happens if you increment "data" beyond SHORT_MAX, depends on
  40. the implementation. (Some of these points were discussed at the C++ Committee
  41. meeting last week, and it was decided not to specify the behavior. The
  42. reason is that so much depends on the implementation already that there
  43. isn't much the standard could usefully say.)
  44.  
  45. >Since the draft says nothing specifically about the type of a bit-field
  46. >member, I assume that it is the type of the member ignoring the bit-field
  47. >specifier.
  48.  
  49. That is correct. The bitfield specification is a request to the compiler to
  50. perform some implementation-dependent packing of the data. The type of the
  51. member is the declared type. (Use a too-short bitfield at your own risk.)
  52.  
  53. >Finally, the promotion of a bit-field is specified in 4.5, Integral
  54. >promotions.  It specifies that all non-enum bit-fields promote to 'int' or
  55. >'unsigned int'.  This seems wrong for 'long' and 'unsigned long'
  56. >bit-fields. 
  57.  
  58. That has already been fixed. The current draft says promotion occurs only
  59. if type int (or unsigned int) can represent all the values of the bitfield.
  60. If the bitfield is larger, no promotion occurs.
  61.  
  62. ---
  63. Steve Clamage, stephen.clamage@eng.sun.com
  64. ---
  65. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  66.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  67.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  68.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  69.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  70. ]
  71.